{"id":38232,"date":"2010-09-08T20:12:43","date_gmt":"2010-09-08T20:12:43","guid":{"rendered":"https:\/\/www.vmengine.net\/2010\/09\/08\/computacion-en-la-nube-frente-a-infraestructura-fisica\/"},"modified":"2025-05-23T17:08:37","modified_gmt":"2025-05-23T17:08:37","slug":"computacion-en-la-nube-frente-a-infraestructura-fisica","status":"publish","type":"post","link":"http:\/\/temp_new.vmenginelab.com\/es\/2010\/09\/08\/computacion-en-la-nube-frente-a-infraestructura-fisica\/","title":{"rendered":"Computaci\u00f3n en la nube frente a infraestructura f\u00edsica"},"content":{"rendered":"

\"\"<\/a>\"\"<\/a><\/p>\n

Este art\u00edculo es una traducci\u00f3n de un post de Fr\u00e9d\u00e9ric Faure<\/a> (arquitecto de sistemas en Ysance<\/a>) sobre las diferencias entre utilizar una infraestructura de computaci\u00f3n en la nube como AWS y construir la propia f\u00edsica. Lo informamos porque creemos que el art\u00edculo es muy correcto.<\/p>\n

He notado muchas preguntas sobre las diferencias inherentes a la elecci\u00f3n
\nentre una infraestructura en la nube como AWS (Amazon Web Services) y un
\ninfraestructura f\u00edsica tradicional. En primer lugar, hay una serie de
\nnociones preconcebidas sobre este tema que tratar\u00e9 de descifrar para ti.
\nEntonces, hay que entender que cada infraestructura tiene sus ventajas y
\nDesventajas: Una infraestructura en la nube t\u00edpica no tiene por qu\u00e9 cumplir necesariamente sus requisitos
\nrequisitos en cualquier caso, sin embargo, debe ser capaz de cumplir algunos de ellos
\nOptimizando o facilitando las funcionalidades que ofrece una infraestructura f\u00edsica tradicional. <\/em>A continuaci\u00f3n, demostrar\u00e9 las diferencias que he notado entre los dos m\u00e9todos, con el fin<\/em> de ayudarle a tomar su propia decisi\u00f3n.<\/em><\/p>\n

El marco<\/em><\/h3>\n

Nube<\/em><\/p>\n

Hay diferentes tipos de posibilidades para usar la nube y continuar\u00e9 hablando de AWS, que son
\nservicios orientados a la infraestructura, en lugar de servicios del tipo Google (GAE – Google App Engine),
\npor nombrar uno, que proporciona un entorno de ejecuci\u00f3n para sus aplicaciones web desarrolladas con
\nlas API proporcionadas (similares a un marco). En realidad, en lo que respecta a estos \u00faltimos, no podemos hablar por los clientes (los que usan la tarjeta de cr\u00e9dito) sobre la gesti\u00f3n de la infraestructura, porque cargamos nuestra aplicaci\u00f3n utilizando las API proporcionadas y dejamos toda la gesti\u00f3n de la infraestructura al proveedor de servicios. Esto no quiere decir que se trate de un servicio menor de computaci\u00f3n en la nube, sino simplemente otro tipo de servicio en la nube, m\u00e1s orientado a la PaaS de orientaci\u00f3n a la infraestructura.<\/em><\/p>\n

\"\"<\/a><\/em><\/p>\n

Infraestructura f\u00edsica<\/em><\/h3>\n

En lo que respecta a las infraestructuras f\u00edsicas, examinar\u00e9 el concepto de infraestructuras autoalojadas y, al mismo tiempo, la noci\u00f3n de infraestructura mantenida por un proveedor de alojamiento. Del mismo modo, me centrar\u00e9 en las infraestructuras basadas directamente en hardware, as\u00ed como en las basadas en entornos virtualizados <\/em>. La computaci\u00f3n en la nube tambi\u00e9n se basa en la virtualizaci\u00f3n, pero no estamos tan interesados en esa tecnolog\u00eda aqu\u00ed, sino en la forma en que se entrega a los clientes (usted). De hecho, simplemente puede lanzar instancias a trav\u00e9s de una consola, como lo hace para EC2, si tiene un ESX (VMware), por ejemplo, pero es \u00absolo\u00bb un hipervisor que divide el servidor f\u00edsico en varias m\u00e1quinas virtuales. Todav\u00eda tendr\u00e1 que lidiar con la compra de equipos (blades, etc.), la configuraci\u00f3n de la red, etc. Pero volveremos a esos detalles m\u00e1s adelante.<\/em><\/p>\n

Computaci\u00f3n en la nube = \u00bfAdministradores de sistemas rebajados?<\/em><\/h3>\n

\u00a1S\u00ed, las ventas est\u00e1n en marcha! \u00bfEst\u00e1s buscando un su\u00e9ter, una chaqueta, … \u00bfUn administrador de sistemas? A menudo se encuentra con personas que piensan que la nube (en el caso de AWS) les permitir\u00e1 habilitarlos sin un administrador de sistemas experimentado y construir una infraestructura con menos experiencia. La respuesta es obvia: \u00a1INCORRECTO!<\/em><\/p>\n

Tal vez un argumento de venta inteligente pueda convencerlo de que los diversos servicios son tan f\u00e1ciles de usar, que puede hacerlo todo usted mismo y que las AMI preempaquetadas (Amazon Machine Image) le facilitar\u00e1n la vida, pero no hace falta decir que una vez que lanza sus instancias EC2, se conecta a las computadoras (SSH \/ puerto 22 para Linux y TSE \/ puerto 3.389 para Windows), Luego tendr\u00e1s que establecer par\u00e1metros, hacer la afinaci\u00f3n, etc.<\/em><\/p>\n

Lo que es cierto para los administradores de sistemas frente a AWS tambi\u00e9n lo es para los arquitectos de sistemas en el campo de los servicios de computaci\u00f3n en la nube que dan acceso a las capas m\u00e1s altas (PaaS como Google App Engine). Es necesaria una persona con experiencia en el campo, capaz de configurar los requisitos de infraestructura: la herramienta puede cambiar, pero las habilidades deben seguir estando disponibles. Tenga en cuenta, sin embargo, que si utiliza
\nGAE, no necesita un administrador de sistemas para la aplicaci\u00f3n. Si el Editor de servicios en la nube ofrece un servicio en un nivel determinado (Haas, IAAS, PaaS, etc.), ya no es necesario que el personal administre las capas inferiores. Sin embargo, aceptamos el marco proporcionado por el proveedor de la nube.<\/em><\/p>\n

Los administradores de sistemas no pueden ser eliminados, pero su papel est\u00e1 cambiando: se est\u00e1n convirtiendo en algo m\u00e1s que un desarrollador. De hecho, poder tirar de recursos sobre la marcha permitir\u00e1 una gesti\u00f3n de la infraestructura programable y automatizable a trav\u00e9s de scripts, que llamar\u00e1n a las APIs proporcionadas por Amazon que permite la comunicaci\u00f3n con sus servicios web. Todo en Amazon es webServices: EC2, EBS, SQS, S3, SimpleDB: la \u00fanica operaci\u00f3n no SOAP o REST que existe es cuando nos conectamos directamente a las instancias EC2 que hemos invocado a trav\u00e9s del WebService o cuando las instancias EC2 hablan con el EBS que hemos invocado a trav\u00e9s del … Te dejar\u00e9 adivinando.<\/em><\/p>\n

El administrador puede entonces, en lugar de ir a la sala de servidores, a\u00f1adir un disco, conectar un servidor (en el caso de una arquitectura f\u00edsica) o coger el tel\u00e9fono y pedir al proveedor de alojamiento que lo haga (tomar un caf\u00e9 … Llame de nuevo… tomar un Xanax o una pastilla de Prozac…), solicitar recursos a trav\u00e9s de un script en Ruby o Python… As\u00ed podr\u00e1s automatizar la infraestructura Cloud y mucho, mucho m\u00e1s, adem\u00e1s, con una serie de scripts y herramientas.<\/em><\/p>\n

Por lo tanto, la profesi\u00f3n del administrador de sistemas est\u00e1 evolucionando entre una infraestructura f\u00edsica y una infraestructura en la nube como AWS: siempre ser\u00e1 m\u00e1s que un desarrollador. Sin embargo, los administradores de sistemas siguen siendo esenciales.<\/em><\/p>\n

\u00a1Elastic es genial!<\/em><\/h3>\n

Como dec\u00eda antes, una de las diferencias esenciales entre ambos tipos de infraestructuras es la flexibilidad y el dinamismo que aporta la soluci\u00f3n Cloud, frente a una arquitectura f\u00edsica tradicional (ya sea basada en virtualizaci\u00f3n o no). Esto significa la eliminaci\u00f3n del tiempo
\nNecesario para instalar y configurar la log\u00edstica (compra de equipos, instalaci\u00f3n del sistema operativo, conexi\u00f3n a la red – red f\u00edsica y configuraci\u00f3n de interfaces, etc.) Del mismo modo, cuando
\nya no necesita una pieza de hardware (una instancia virtual EC2, un volumen EBS, un objeto S3, etc.), puede devolverlo al grupo de recursos: se reinicializar\u00e1 para que no se pueda recuperar ninguno de sus datos, y
\nvuelve a estar disponible hasta la pr\u00f3xima llamada al servicio web.<\/em><\/p>\n

Tambi\u00e9n tiene acceso completo a ciertos elementos, como los grupos de seguridad (firewalls) establecidos para cada instancia… Y esto es muy \u00fatil. Es muy pr\u00e1ctico, especialmente en comparaci\u00f3n con un proveedor de alojamiento tradicional: \u00bfrecuerdas la \u00faltima vez que tuviste que cambiar las reglas de tu firewall?<\/em><\/p>\n

Pero no se trata solo de los pros y los contras de comprar el servidor en comparaci\u00f3n con las instancias en ejecuci\u00f3n. Los servicios de AWS est\u00e1n respaldados por centros de datos que ya est\u00e1n organizados y probados industrialmente. Todas las normas de seguridad
\nque debe cumplirse en t\u00e9rminos de protecci\u00f3n contra incendios, refrigeraci\u00f3n de los sistemas, redundancia el\u00e9ctrica de la fuente de alimentaci\u00f3n, seguridad f\u00edsica contra robos, distribuci\u00f3n del hardware en 2 o m\u00e1s
\nLos centros de datos f\u00edsicos para la recuperaci\u00f3n de desastres, etc. implican una inversi\u00f3n inicial y colosal, incluso cuando todo est\u00e1 instalado, a\u00fan no podr\u00e1 recrear la misma calidad dentro de su empresa
\n(99% de las veces, en cualquier caso). Sin embargo, puede lograr todo esto, o parte de ello, con un proveedor de alojamiento tradicional.<\/em><\/p>\n

Pero tambi\u00e9n est\u00e1n todos los servicios tipo software, como la duraci\u00f3n de la gesti\u00f3n de datos (Redundancia\/Replicaci\u00f3n, en EBS y en S3), la accesibilidad o alta disponibilidad, la monitorizaci\u00f3n del hardware (para recibir una alerta cuando los componentes f\u00edsicos muestran signos de debilitamiento), los procedimientos
\npor aver\u00edas, etc. Te dejar\u00e9 leer los 9 principios de S3<\/a><\/em> (versi\u00f3n en franc\u00e9s), para entender cu\u00e1nto conceptos se incluyen. No lograr\u00e1s todo eso con un proveedor de alojamiento tradicional (y olvidarte de ti @Home). La calidad del servicio S3 es en realidad una gran ventaja, especialmente en comparaci\u00f3n con los precios actuales… \u00a1Hablemos de precios!<\/em><\/p>\n

Costos<\/em><\/h3>\n

No hay reglas fijas. Con la nube, pagas por el recurso por hora y cuando ya no lo usas, dejas de pagar. Las instancias tambi\u00e9n se pueden reservar por un a\u00f1o o tres a\u00f1os: instancias reservadas: pagas una tarifa al principio y luego pagas la tarifa de uso a una tarifa subsidiada, lo que te lleva a un punto de no retorno de un determinado
\nPorcentaje de utilizaci\u00f3n de recursos a lo largo del a\u00f1o (o tres a\u00f1os).
\nPara calcular f\u00e1cilmente cu\u00e1nto le costar\u00e1 su infraestructura, utilice la nueva calculadora <\/a> <\/em>proporcionado por Amazon. En todos los casos, una parte est\u00e1 relacionada
\nal uso horario y otro al tr\u00e1fico\/volumen almacenado.<\/em><\/p>\n

\"\"<\/a><\/em><\/p>\n

Puedes comparar el costo de tu infraestructura local o tu hosting
\nproveedor. El precio fijo de la nube es particularmente atractivo en los siguientes casos:
\n<\/em><\/p>\n